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(54) Permit for controlling access to services in protected memory systems 

(57) One embodiment of the present invention pro- 
vides a method and an apparatus for controlling access 
to services in a protected memory system. The method 
makes use of a permit, which includes an access con- 
trol mechanism (500) that resides in a memory space 
that is protected from a user of the permit The method 
includes receiving a request for a service through a per- 
mit, the permit comprising an object (300) defined within 
an object-oriented programming system. In response to 
the request the method activates an access control 
mechanism within the permit. This access control 
mechanism controls access to the service and resides 
in a memory space that is protected from a user of the 
permit such that the access control mechanism is trig- 
gered by invoking (502) a method (306-310) on the per- 
mit if the access is allowed, the method accesses the 
service by performing an invocation (506) on a control- 
led object (320). This controlled object includes meth- 
ods (324-328) to perform the service, and is otherwise 
protected from the user of the permit. Another variation 
of the above embodiment includes receiving, at a permit 
issuing authority, a request for the permit from an entity 
(such as a person, a computer program or a computer 
process) requiring access to the service, if the request 
includes valid authorisation information, a permit is 
issued (412) to the entity. A further variation of the 
above embodiment includes creating a copy of the per- 
mit and transferring the copy to an entity requiring 
access to the service. 
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Description 
BACKGROUND 



100011 The present invention relates to protection 
Kanisms in computer systems. More «P«*""* 
Sresertinvention relates to a method and an appa- 
^ toTcontroliing access to service ipnrn** by 

Tof devCme^ such as Java, it is becoming 

Sedto ailow ^mputer applications frcm d»* 
vendors to interact with each other « a con^dh *ay 
so that the applications can worKt<^erthertoaax)rnpl sh 
a Jventes^One problem indoing so is thatappUcaUon 
veSypically want to control the way «i *•£ 
WeSorS take place. For example, itmay be useful for 
a S ^Hcation to access capita, gains irtorrnaton 

brote rage ^^^S^^^J- 

- accesses to 

LTcU in computer systems has been handled 
£X? hardware mechanisms, such as hardware 

"eh as a Java™ applet which is designed to operate 
across a wide range of computing platforms. 

SUMMARY 

rooo51 One embodiment of the present invention pro- 
El meSTand an apparatus tor controlling access 
to services provided by other applicatons. Themethod 
l^kesuse of a permit, which includes an access con- 
STec^m Eat resides in a memory spacethat^ 
Sotec^ed from a user of the perrnrt The method 
frliesreceivinga^ 

mit. the permit comprising an a***. «"«J^S ^ 
object-oriented programming system. In response to 
SeTequest the method activates an access oontro 
ISsm within the permit This access cor*o, 
mechanism controls access to the serv.ce and resides 
*f memory space that is protected from a user of the 



permit, such that the access control <™*^ - W 
Sered by invoking a method on the perrnrt. If the access 
TaTowed the method accesses the service by par- 
VX an invocation on a controlled object This con- 
s S oSiect includes methods to perforrr .the ^service. 

SmTf!om an entity (such as a person, a computer 
n^ram oTa computer process) requiring access to tte 

I oeTnTis issued to the entity. A further vana- 

inc,udes oreating *£Z 

Tito permit and transferring the copy to an entity 
« requiring access to the service. 

100061 Thus, the present invention provries a method 
S^ntroWng access to a service provided by another 
SSXV method does not rely , « , hardware 
access control mechanisms, and hence can oe 
20 . empSed by a portable application across a w-de range 
of computing platforms. 
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FIG. 1A illustrates code modules working together 
within computer system in accordance wrth an 
embodiment of the present invention. 
FIG. 1B illustrates a number of computer nodes 
coupled together through a network m accordance 
with an embodiment of the present invention. 
FIG ^illustrates the process of accessing a serv,ce 
fn accordance with an embodiment of the present 

Hatlstrates the structure of a perrnrt obiect 
and a controlled object 320 in accordance wrth an 
embodiment of the present invention. 
FiG 4 is a flow chart illustrating the process ofcre- 
ating a permit object in accordance with an embod- 
iment of the present invention. 
ST Sto a flow chart illustrating the process of 
using a permit object to access a service .naccorf- 
Sce with an embodiment of the present .nvention. 



DETAILED DESCRIPTION 



[0008] The following description is presented to ena- 
homv oerson skilled in the art to make and use the 

Sed Sin may be applied to other 
55 and applications without departing from the spirit and 

S is not intended to be limited to the ernbodinrcnte 
Sown, but is to be accorded the widest scope consist- 
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ent with the principles and features disclosed herein. 

Distributed Computer System 

[0009] FIG. 1 A illustrates code modules 102 and 104 
working together within computer system 100 in accord- 
ance with an embodiment of the present invention. In 
order to work with code module 104, code module 102 
requests services from code module 104. Similarly, in 
order to work with code module 102, code module 104 
requests services from code module 102. Access to 
services between modules 102 and 104 is controlled 
through the permit structure described in more detail 
with reference to FIGs. 3-5 below. 
[0010] For purposes of this detailed description, a 
service is a function made available by a first application 
to other applications. This function may provide the 
other applications with access to data or to computa- 
tional resources from the first application. A protected 
memory system is a system that facilitates protection of 
selected regions of memory from an application running 
on the system. 

[0011] FIG. 1B illustrates how the present invention 
can be used in a client-server computer context in which 
a number of computer nodes coupled together through 
a network 1 30 in accordance with an embodiment of the 
present invention. In FIG. 1. servers 110 and 120 are 
coupled to third-party system 140 through network 130. 
Network 130 generally refers to any type of wire or wire- 
less link between computers, including, but not limited 
to. a local area network, a wide area network, or a com- 
bination of networks. In one embodiment of the present 
invention, network 130 includes the Internet Servers 
110 and 120 can be any nodes on a computer network 
including a mechanism for servicing requests from a cli- 
ent for computational or data storage resources. Third- 
party system 140 may be any node a computer network 
communicating with servers 1 10 and 120 that is able to 
download code and/or data from servers 110 and 120. 
[001 2] In the embodiment illustrated in FIG. 1 , server 
110 contains server code module 112, and server 120 
contains client code module 122. Server code module 
1 1 2 and client code module 122 include modular pieces 
of code that can operate together on third-party system 
140. The dashed lines in FIG. 1 represent server code 
module 112 and client code module 122 being down- 
loaded onto third-party system 140 across network 130. 
This downloading process can take place in a number 
of waya In one embodiment of the present invention, 
server 110 includes a web site that can be accessed by 
a user on third-party system 140 to download server 
code module 112 onto third-party system 140. Corre- 
spondingly, server 120 includes a web site that can be 
accessed by a user on third-party system 1 40 to down- 
load client code module 122 into third-party system 140. 
In another embodiment, server code module 112 and 
client code module 122 are not downloaded across net- 
work 130. Instead, they are transferred from servers 



110 and 120, respectively, to third-party system 140 by 
way of computer storage media, such as a computer 
disk. 

[001 3] Once server code module 1 1 2 and client code 
5 module 122 are located on third-party system 140, they 
can be integrated to work together as is illustrated in 
FIG. 1 . For example, in providing a service to client code 
module 122, server code module 112 might retrieve 
data from a database for client code module 1 22. Aher- 
w natively, server code module 1 1 2 might perform a com- 
putational operation for client code module 122. This 
integration process may involve determining whether 
client code module 122 has been conferred the right to 
access services from server code module 112. In the 
is reverse direction, this process may involve determining 
whether server code module 112 has been conferred 
the right to access services from client code module 
122. 

20 Process of Accessing a Servfre 

[0014] FIG. 2 illustrates the process of accessing a 
service in accordance with an embodiment of the 
present invention. FIG. 2 illustrates interactions 

25 between server gate 202, system 204 and client code 
module 122 (from FIG. 1). Note that the process for 
accessing a service illustrated in FIG. 2 represents only 
one possible method of obtaining access to a service. In 
general, the present invention applies to any pieces of 

30 code working together in a computer system. Server 
gate 202 is a mechanism that provides permits to prop- 
erly authorized requesters. 

[001 5] For purposes of this detailed description, a per- 
mit is a token held by an entity, which allows the entity to 

35 access a service. In one embodiment of the present 
invention, a permit includes an object defined within an 
object oriented programming system that facilitates 
accesses to a collection of services. 
[0016] Server gate 202 includes an access control 

40 mechanism that controls access to services provided by 
servercode module 112 (from FIG. 1). This access con- 
trol mechanism can require varying levels of authentica- 
tion from a requester of a permit. In one embodiment of 
the present invention, server gate 202 is located within 

45 server code module 1 12 on third-party system 140. In 
another embodiment, server gate 202 is located within 
server 110 itself, and is accessed via communications 
across network 130. System 204 includes a mechanism 
for establishing that client code module 122 is properly 

so authorized to access services provided by server code 
module 1 12. To this end, system 204 is implemented in 
a number of ways. In one embodiment, system 204 is 
implemented by code that is part of third-party system 
140. In another embodiment, system 204 may be impie- 

55 merited as part of server code module 112 within third- 
party system 140. 

[0017] The process illustrated in FIG. 2 operates as 
follows. Client code module 122 is assumed to already 
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exist within third-party system 1 40. In order to access a 
desired service, client code module 122 requests a 
"ticket" for a "role" to access a collection of services 
from server code module 112. A role defines a set of 
operations to be performed by server code module 112. 
Certain roles may be more limited than other roles. For 
example, if server code module 112 maintains a compu- 
ter file system, one role may include only the operation 
of reading a file from the file system. Another more pow- 
erful role may include the operations of reading, writing 
and deleting files from the file system. 
[0018] In response to the request, system 204 exam- 
ines client code module 122, to determine if client code 
module 122 includes proper authorization for the role. In 
one embodiment of the present invention, this examina- 
tion includes examining a certificate chain. This process 
is described in more detail in a co-pending European 
Patent Application No., entitled "Controlling Access to 
Services Between Modular Applications, " correspond- 
ing to U.S Patent Application Serial No. 09\ 106, 567., 
which is hereby incorporated by reference in order to 
describe this process. 

[001 9] If client code module 1 22 is properly authorized 
for the role, system 204 issues a ticket for the role, and 
this ticket is given to client code module 122. Next, client 
code module 122 passes the ticket to server gate 202. 
Server gate 202 checks the ticket to ensure that the 
ticket is valid. If it is valid, server gate 202 sends a per- 
mit for the service to client code module 122. This per- 
mit allows client code module 122 to access the 
services defined by the role. In one embodiment of the 
present invention, this permit is an object defined within 
an object-oriented programming system. This object 
allows client code module 122 to perform a set of meth- 
ods that comprise the role. After the permit is sent, 
server gate 202 invalidates the ticket, so that it cannot 
be used again. Since client code module 1 22 remains in 
possession of the permit client code module 122 will be 
able to access services using the permit, and hence, no 
longer needs the ticket. 

Permit Object 

[0020] FIG. 3 illustrates the structure of a permit 
object 300 and controlled object 320 in accordance with 
an embodiment of the present invention. Permit object 
300 is typically held by a client code module, such as cli- 
ent code module 122 (from FIG. 1), which requires 
access to services provided by a server code module, 
such as server code module 1 12 (from FIG. 1). Server 
code module 112 maintains controlled object 320, 
which contains code and data used to implement the 
services. Note that the embodiment illustrated in FIG. 3 
is implemented through objects defined within an 
object-oriented programming system. However, the 
invention is not limited to object-oriented programming 
systems. 

[0021 ] Permit object 300 includes a number of compo- 



nents including controlled object pointer 302, boolean 
vector 304, method-0 pointer 306, method- 1 pointer 
308, method-N pointer 310, permit creation method 
312, permit expiration information 314 and permit log 
5 316. 

[0022] Controlled object pointer 302 points to control- 
led object 320, which is maintained by server code mod- 
ule 112, and thereby allows the holder of permit object 
300 to access services associated with controlled 

ro object 320 within server code module 112. Controlled 
object pointer 302 is stored in a memory that area that 
is protected from accesses by client code module 122. 
Client code module 122 cannot directly read or modify 
controlled object pointer 302. Client code module 122 

is cannot access controlled object 320 directly. In order to 
access controlled object 320, client code module 122 
must ask the system to access controlled object 320 
through controlled object pointer 302. Similarly, the 
other data items within permit object 300 are protected 

20 so they cannot be directly read or modified by client 
code module 122. This memory protection ensures that 
client code module 122 must access services associ- 
ated with controlled object 320 by asking the system to 
access the services. This enables the system to restrict 

25 access to the services in a manner that is specified by 
the permit. 

[0023] As mentioned above, this type of memory pro- 
tection can be provided by using the Java™ program- 
ming language and supporting interfaces. The Java™ 

30 programming language supports memory protection 
down to the object level. Under the Java model, the only 
way to access data within an object is by invoking meth- 
ods supported by the object Data within an object is 
otherwise protected from memory references - through 

35 a stray pointer for example. Since the Java™ program- 
ming language can be ported across a wide range of 
computing platforms, this object level memory protec- 
tion can be provided across a wide range of computing 
platforms. However, note that it may be possible to get 

40 around the protection mechanism by attacking the inter- 
face between the Java programming language and the 
operating system on a particular computing platform. In 
order to prevent this type of attack, the Java™ memory 
protection scheme can be extended into the hardware 

45 of a computing platform. 

[0024] Boolean vector 304 contains entries corre- 
sponding to methods provided by controlled object 320. 
These methods implement the services associated con- 
trolled object 320. If an entry includes an "ALLOWED" 

so value, this indicates that the holder of permit object 300 
is allowed to access the corresponding method that 
implements the service from controlled object 320. If the 
entry includes a "NOT ALLOWED" value, this indicates 
the holder of the permit is not allowed to access the cor- 

55 responding method. In this way, permit object 300 spec- 
ifies which services the holder of the permit is allowed to 
access. Since boolean vector 304 is located in pro- 
tected memory, a holder of permit object 300 cannot 
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modify boolean vector 304 to gain unauthorized access 
to a service. Note that there are many possible ways to 
indicate that particular methods are not allowed. In 
another embodiment, methods within permit object 300 
are coded to call a corresponding method in controlled 
object 320. Otherwise, they are coded to indicate that 
the method is not allowed. 

[0025] The methods specified in controlled object 320 
are accessible through method pointers within permit 
object 300. These method pointers include method-0 
pointer 306, method- 1 pointer 308 and method-N 
pointer 310. Client code module 1 22 must access meth- 
ods 324, 326 and 328 through these method pointers 
306, 308 and 310. Method-0 pointer 306 points to 
method-0 324 within controlled object 320. Method-1 
pointer 308 points to method-1 326 within controlled 
object 320. Method-N pointer 310 points to method-N 
328 within controlled object 320. These method pointers 
reside in protected memory so that client code module 
122 must access the methods through the system. 
[0026] In the illustrated embodiment, permit object 
300 additionally includes permit creation method 312, 
which allows a holder of permit object 300 to create a 
copy of permit object 300, and to transfer the copy to 
another application. This allows client code module 1 22 
to farm out a sub-task requiring services from controlled 
object 320 to another module. Note that permit creation 
method 312 allows only less powerful copies of permit 
object 300 to be mada In other words, copies of permit 
object 300 can access at most the same methods from 
controlled object 320, and possibly fewer methods. 
[0027] Permit object 300 additionally includes permit 
expiration information, which specifies some type of 
lifespan limitation for the permit. In one embodiment, 
this is accomplished by specifying a certain time period 
during which the permit is valid. In another embodiment 
this is accomplished by requiring that the system first 
check in a central database to see that the permit 
remains still valid. 

[0028] Permit object 300 also includes permit log 316, 
which records a log of access requests to permit 300. 
This log can be used for security purposes to monitor 
how permit object 300 is being used. Alternatively, a log 
of access requests can be maintained within controlled 
object 320. 

[0029] Controlled object 320 contains data 322, which 
is used by methods 324, 326 and 328 to implement 
services associated with controlled object 320. For 
example, data 322 may contain file system data and 
methods 324. 326 and 328 may specify file system 
operations. 

Permit QreaHort 

[0030] FIG. 4 is a flow chart illustrating the process of 
creating a permit object in accordance with an embodi- 
ment of the present invention. This flow chart describes 
in more detail the operations performed by server gate 



202, which were described previously with reference to 
FIG. 2 above. The system starts at state 400 and pro- 
ceeds to state 402. In state 402, client code module 122 
performs an invocation on server gate 202 to make a 

5 new permit As mentioned above, this invocation 
includes a ticket for a role as a parameter. The system 
then proceeds to state 404. In state 404, server gate 
202 authenticates the ticket, and if it is valid, server gate 
202 makes a new permit object 300. This process may 

w include locating a controlled object 320 to associate 
with permit object 300, or if necessary, making a new 
controlled object 320 within server code module 112. 
The system next proceeds to state 408. In state 408, 
controlled object pointer 302 (from FIG. 3) is assigned 

is to point to controlled object 320. The system next pro- 
ceeds to state 410. In state 410, the system sets access 
control flags (entries in boolean vector 304) to specify 
which methods the holder of the permit is allowed to 
invoke. The system next proceeds to state 410. In state 

20 410, permit object 300 is returned to client code module 
1 22. The system next proceeds to state 41 4, which is an 
end state. 

Use of Permit Object 

25 

[0031] FIG. 5 is a flow chart illustrating the process of 
using a permit object to access a service in accordance 
with an embodiment of the present invention. The sys- 
tem starts at state 500 and proceeds to state 502. In 

30 state 502. client code module 1 22 (from FIG. 1 ) invokes 
a method on permit object 300 (from FIG. 3). The sys- 
tem proceeds to state 504. In state 504, the system 
checks access control flags corresponding to the 
method. This entails looking up an entry in boolean vec- 

35 tor 304 corresponding to the invoked method. If this 
access control flag indicates the method is allowed, the 
system proceeds to state 506. Otherwise, the system 
proceeds to state 51 0. 

[0032] In state 506 the access is allowed, so the sys- 
40 tern invokes the appropriate method on permit object 
300, which causes a corresponding method to be 
invoked on controlled object 320 with the appropriate 
parameters. The system next proceeds to state 508, In 
state 508, the system waits for the invocation to com- 
45 plete, and then returns a result to client code module 
1 22. The system next proceeds to state 512, which is an 
end state. 

[0033] In state 510, the method is not allowed. In this 
case, the system indicates to client code module 122 

50 that the method is not allowed. This can be done in a 
number of waya In one embodiment of the present 
invention, the system causes an exception to occur in 
the execution stream of a processor performing the 
method invocation. In another embodiment, the system 

55 sets a global variable to indicate that the attempted use 
of permit object 300 failed. In yet another embodiment, 
the invocation to permit object 300 returns a NULL 
value. The above process is repeated for successive 
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invocations on permit object 300. 
[0034] The foregoing descriptions of embodiments of 
the invention have been presented for purposes of illus- 
tration and description only. They are not intended to be 
exhaustive or to limit the invention to the forms dis- s 
closed. Accordingly, many modifications and variations 
will be apparent to practitioners skilled in the art 

Claims 

w 

1 . A method for controlling access to services in a pro- 
tected memory system, comprising: 



2. The method of claim 1, wherein the access control 
mechanism (500) provides access to the service by 
performing an invocation (506) on a controlled 30 
object (320), the controlled object including a 
method (324-328) to perform the service, and oth- 
erwise being protected from the user of the permit 

3. The method of claim 1 or claim 2, further compris- 35 
ing if the access is not allowed, indicating (510) to 

an entity requesting the service that the access to 
the service is not allowed. 

4. The method of claim 1 or claim 2, wherein the per- 40 
mrt (300) is defined within the Java™ programming 
language and supporting interfaces. 

5. The method of any one of claims 1 to 4 f wherein 
data (322) protected by the permit (300) can only 4s 
be accessed through methods (306-310) invoked 

on the permit. 

6. The method of any one of claims 1 to 5, further 
comprising: so 

receiving, at a permit issuing authority, a 
request for the permit from an entity requiring 
access to the service: and 

if the request includes valid authorisation infor- ss 
mation, issuing the permit (412) to the entity. 

7. The method of any one of claims 1 to 6, further 



comprising creating a copy of the permit (300) and 
transferring the copy to an entity requiring access to 
the service. 

8. The method of claim 7, wherein the copy of the per- 
mit allows access to fewer services than the permit 
(300) that it was copied from. 

9. The method of any one of claims 1 to 8, further 
comprising determining whether the permit has 
been revoked before accessing the service, and 
been revoked, indicating (510) the access is not 
allowed. 

10. The method of any one of claims 1 to 9, further 
comprising recording the access request in a log 
(31 6) associated with the permit 

11. The method of any one of claims 1 to 10, wherein 
activating the access control mechanism includes 
determining (314) whether the permit has expired. 

12. The method of any one of claims 1 to 11, wherein 
the access control mechanism includes a pointer 
(302) to the controlled object (320), the pointer 
residing in the memory space that is protected from 
the user of the permit. 

13. The method of any one of claims 1 to 12, wherein 
the access control mechanism includes a method 
(324-328) to be invoked to perform the service, 
wherein if access is not allowed, the method (324- 
328) does not perform the service, but instead indi- 
cates (510) that access to the service is not 
allowed. 

14. The method of any one of claims 1 to 13, wherein 
the access control mechanism includes a variable 
(304) associated with a method to be invoked to 
perform the service, wherein the variable indicates 
whether the access is allowed. 

15. A computer readable storage medium storing 
instructions that when executed by a computer 
cause the computer to perform a method for con- 
trolling access to services in a protected memory 
system, comprising: 

receiving a request for a service through a per- 
mit, the permit comprising an object (300) 
defined within an object-oriented programming 
system; 

in response to the request, activating an 
access control mechanism (500) within the per- 
mit, the access control mechanism controlling 
access to the service and residing in a memory 
space that is protected from a user of the per- 
mit such that the access control mechanism is 



receiving a request for a service through a per- 
mit, the permit comprising an object (300) 75 
defined within an object-oriented programming 
system: 

in response to the request, activating an 
access control mechanism (500) within the per- 
mit, the access control mechanism controlling 20 
access to the service and residing in a memory 
space that is protected from a user of the per- 
mit, such that the access control mechanism is 
triggered by invoking (502) a method (306-31 0) 
on the permit: and 25 
if the access is allowed, accessing the service. 
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triggered by invoking (502) a method (306-310) 
on the permit; and 

if the access is allowed, accessing the service 
by performing an invocation (506) on a control- 
led object (320), the controlled object including s 
a method (324-328) to perform the service, and 
otherwise being protected from the user of the 
permit 

16. An apparatus for controlling access to services in a w 
protected memory system, comprising: 

a permit means through which a user can 
access a service, the permit means optionally 
comprising an object (300) defined within an 15 
object-oriented programming system; 
an access control means (500) within the per- 
mit the access control means controlling 
access to the service and residing in a memory 
space that is protected from a user of the per- 20 
rrrit, such that the access control means is trig- 
gered by invoking (502) a method (306-310) on 
the permit; and 

a request processing means, in communication 
with the permit means, that is configured to 25 
receive an access request for the service 
through the permit means, and to activate the 
access control means. 

17. The apparatus of claim 1 6, wherein the access con- 30 
trol means (500) is configured to provide access to 
the service by performing an invocation (506) on a 
controlled object (320). the controlled object includ- 
ing a method (324-328) to perform the service, and 
otherwise being protected from the user of the per- 35 
mit (300). 

18. Trie apparatus of claim 16 or claim 1 7, wherein the 
request processing means is configured to indicate 

(51 0) that the access to th e service is not allowed if 40 
the request processing means determines that the 
access is not allowed. 

19. The apparatus of any one of claims 16 to 18, 
wherein the access control means (500) includes at 45 
least one method (324-328) to be invoked to per- 
form the service. 

20. The apparatus of any one of claims 16 to 19, 
wherein the permit (300) is defined within the so 
Java™ programming language and supporting 
interfaces. 

21. The apparatus of any one of claims 16 to 20, 
wherein data (322) protected by the permit (300) ss 
can only be accessed through methods (306-310) 
invoked on the permit. 



22. The apparatus of any one of claims 1 6 to 21 , further 
comprising a permit creation mechanism (400) that 
receives a request for the permit (300) from an 
entity requiring access the service, and if the 
request includes valid authorisation information, 
issues (41 2) the permit to the entity. 

2a The apparatus of any one of claims 1 6 to 22, further 
comprising a permit copying mechanism that is 
configured to create a copy of the permit (300) and 
to transfer the copy of the permit to an entity requir- 
ing access to the service. 

24. The apparatus of any one of claims 16 to 23, 
wherein the permit copying mechanism is config- 
ured to produce the copy of the permit that allows 
access to fewer services than the permit (300) it 
was copied from. 

25. The apparatus of any one of claims 16 to 24, 
wherein the request processing means is config- 
ured to determine (504) whether the permit has 
been revoked before accessing the service. 

26. The apparatus of any one of claims 16 to 25, further 
comprising a log (316), associated with the permit, 
to record access requests. 

27. The apparatus of any one of claims 16 to 26, 
wherein the request processing means is config- 
ured to determine (314) whether the permit has 
expired. 

28. A data structure contained in a computer readable 
storage medium for controlling access to services 
in a protected memory system, the data structure 
comprising: 

an access control mechanism (500) within the 
data structure, the access control mechanism 
controlling access to the service and residing in 
a memory space that is protected from a user 
of a permit (300), such that the access control 
mechanism is triggered by invoking (502) a 
method (306-310) on the permit; and 
an access control indicator (304) within the 
data structure, the access control indicator 
specifying services the user can access, the 
access control indicator being protected from 
modification by the user. 

29. The data structure of claim 28, wherein the access 
control mechanism (500) includes a pointer to 
code(324-328) that implements the service, the 
pointer residing in the memory space that is pro- 
tected from the user. 



30. The data structure of claim 28 or claim 29, wherein 



1 3 EP0 965 917A1 

the access control indicator (304) includes a varia- 
ble associated with a service, wherein the variable 
indicates whether access to a corresponding serv- 
ice is allowed. 

5 

31. A computer program or applet encoding a set of 
computer instructions for controlling access to serv- 
ices in a protected memory system, which when 
running on a computer is adapted to perform the 
method of any one of claims 1 to 14. io 



15 



20 



25 



30 



35 



40 



45 



50 



55 



EP0 965 917 A1 



^—COMPUTER 
f SYSTEM 
100 * 



CODE . 


CODE 


MODULE <T 


MODULE 


102 ^ 


104 



FIG. 1A 




SERVER 
120 



FIG. 1B 



9 



EP0 965 917 A1 



CLIENT 

SERVER CODE 
GATE SYSTEM N MODULE 

202 204 122 



PASS TICKET TO 
SERVER GATE 


REQUEST TICKET FOR ROLE 


4 

ISSUE TICKET FOR ROLE 
» 




i 


SEND PERMIT TO ACCESS 
RESOURCE THROUGH ROLE 
» 







FIG. 2 



10 



EP0 965 917 A1 



- PERMIT OBJECT 
f 300 







CONTROLLED 
OBJECT POINTER 
302 






BOOLEAN VECTOR 
INDICATING 
ALLOWED METHODS 
304 






Mc I HUU-0 POINTER 
306 






METHOD-1 POINTER 
308 






• 
• 






METHOD-N POINTER 
310 






PERMIT CREATION 
METHOD 
312 






PERMIT EXPIRATION 
INFORMATION 
314 






PERMIT LOG 
316 







CONTROLLED OBJECT 
320 









DATA 






322 






METHOD-0 






324 






METHOD-1 




— > 


326 






• 
• 






METHOD-N 






328 









FIG. 3 



11 



EP0 965 917 A1 



C START X 
400 J 



I 1 

INV( 
SERVE) 
4C 


E 

DKE 
R GATE 
)2 






MAKE 
PERMIT 
4C 


NEW 
OBJECT 
34 



LOCATE CC 
OBJECT OR 
CONTROLL 
4( 


)NTROLLED 
MAKE NEW 
ED OBJECT 
36 







ASSIGN POINTER IN 
PERMIT OBJECT 
TO POINT TO 
CONTROLLED OBJECT 
408 



SET ACCESS CONTROL 

FLAGS TO INDICATE 
METHODS THE ROLE IS 
ALLOWED TO INVOKE 
410 



RETURN PERMIT 
OBJECT 
412 



( END N 

FIG. 4 



12 



EP0 965 917 A1 



C START X 
500 J 



CLIENT CODE 
INVOKES A METHOD 
ON PERMIT OBJECT 
502 



SYSTEM 
CHECKS ACCESS 
CONTROL FLAG 
CORRESPONDING TO 
METHOD 
504 



METHOD NOT ALLOWED 



METHOD ALLOWED 



CALL CORRESPONDING 

METHOD IN 
CONTROLLED OBJECT 
-PASS PARAMETERS 
506 



SIGNAL CLIENT THAT 
METHOD 
NOT ALLOWED 
510 



RETURN 
RESULT 
508 



f END \ 



FIG. 5 



13 



EP0 965 917 A1 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 99 20 1908 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate, 
of relevant passages 



Relevant 
to claim 



CLASSIFICATION OF THE 
APPLICATION (lnt.C1.6) 



GRITZALIS S ET AL: "SECURITY ISSUES 
SURROUNDING PROGRAMMING LANGUAGES FOR 
MOBILE CODE: JAVA RM VS. SAFE-TCL" 
OPERATING SYSTEMS REVIEW (SIGOPS), 
vol. 32, no, 2, 1 April 1998 (1998-04-01), 
pages 16-32, XP000766954 

* page 19, left-hand column, paragraph 1 - 
page 22, left-hand column, paragraph 4 * 

* page 26, right-hand column, paragraph 3 

- page 27, left-hand column, paragraph 2 * 

* page 28, left-hand column, paragraph 1 - 
right-hand column, paragraph 2 * 

WALLACH D S ET AL: "Extensible security 
architectures for Java" 
PROCEEDINGS OF THE ACM SYMPOSIUM ON 
OPERATING SYSTEMS PRINCIPLES , 1997 , pages 
1-26 14, XP002101681 

* page 5, line 7 - page 7, line 11 * 

* page 8, line 9 - page 10, line 13 * 

* page 14, line 1 - line 14 * 

N. ISLAM ET AL: "A Flexible Security 

Model for Using Internet Content" 

IBM : DEVELOPER : JAVA OVERVIEW : LIBRARY 

- PAPERS, 'Online! October 1997 (1997-10), 
XP002115800 

IBM Thomas J. Watson Research Center 

Retrieved from the Internet: 

<URL : http : // www . s of tware . i bm . com/de ve 1 oper 

/1 1 brary/f 1 exsecur 1 ty/> 

'retrieved on 1999-09-17! 

* page 4 * 

* Introduction; figure 2 * 

* page 7, paragraph on Java Implementation 



-/- 



1-31 



G06F9/46 
G06F1/00 



1-31 



TECHNICAL FIELDS 
SEARCHED (lnt.CI.6) 



1-31 



G06F 



The present search report has been drawn up for ail claims 



Ptec* of sMJCft 

THE HAGUE 



Dal* ot comptotlon of &m aeaicn 

20 September 1999 



Powell , D 



CATEGORY OF CITEO DOCUMENTS 

X : particuany relevant if taken alone 

Y : particularly relevant If combined wrth another 

document ot the same category 
A : technological background 
O : non-written disclosure 
P : Intermediate document 



T : theory or principle underlying the Invention 
E : earlier patent document, but published on. or 

after the f iling date 
D : document cited In the application 
L : document cited for other reasons 



& : member of the same patent family, corresponding 
document 



14 



EP 0 965 917 A1 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 99 20 1908 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation ot document with indication, where appropriate, 
of relevant passages 



Relevant 
to claim 



CLASSIFICATION OF THE 
APPLICATION (Int.Ct.ft) 



EP 0 813 133 A (IBM) 

17 December 1997 (1997-12-17) 

* the whole document * 

BLAZE M ET AL: "DECENTRALIZED TRUST 
MANAGEMENT" 

PROCEEDINGS OF THE 1996 IEEE SYMPOSIUM ON 
SECURITY AND PRIVACY, OAKLAND, CA. , MAY 6 
- 8, 1996, 

no. SYMP. 17, 6 May 1996 (1996-05-06), 
pages 164-173, XP000634842 
INSTITUTE OF ELECTRICAL AND ELECTRONICS 
ENGINEERS ISBN: 0-7803-3527-9 

US 5 677 952 A (ROGAWAY PHILLIP W ET AL) 
14 October 1997 (1997-10-14) 



1-31 



TECHNICAL FIELDS 
SEARCHED (lnt.CI.6) 



The present search report has been drawn up for all daim9 



Ptaca of teercft 

THE HAGUE 



Oale of comptoton of tht saatcft 

20 September 1999 



Powell , D 



CATEGORY OF CITED DOCUMENTS 

X : particularly relevant IT taken alone 

Y : partial arty relevant tf combined with another 

document of tne> same category 
A : technological background 
O : non-written disclosure 
P * Intermediate document 



T ; theory or principle underlying the Invention 
E : earlier patent document, but published on. or 

after the filing date 
D : document cited in the application 
L : document cited for other reasons 



& : member of the same patent family, corresponding 
document 



15 



EP0 965 917 A1 



ANNEX TO THE EUROPEAN SEARCH REPORT 
ON EUROPEAN PATENT APPLICATION NO. 



EP 99 20 1908 



This annex lists the patent family membersrelating to the patent documents cited in the above-mentioned European search report. 
The members are as contained in the European Patent Office EDP file on 

The European Patent Office is in no way liable for these particulars which are merely given for the purpose of information. 

20-09-1999 



Patent document 
cited in search report 



Publication 
date 



Patent family 
members) 



Publication 
date 



EP 0813133 



17-12-1997 



JP 10091427 A 



10-04-1998 



US 5677952 



14-10-1997 



US 
EP 
JP 
SG 
US 

us 



5454039 
0658022 
7199808 
44363 
5675652 
5835597 



26-09-1995 
14-06-1995 
04-08-1995 
19-12-1997 
07-10-1997 
10-11-1998 



§ For more details about this annex : see Official Journal of the European Patent Office, No. 12/82 



16 



